/test test-serving

/test test-python-sdk

/test test-golang-sdk

/test test-end-to-end

/test test-end-to-end-redis-cluster

Just a very, um, meta thing—if I saw this changelog and #536 in the same release notes I would think they're related. Should we find some disambiguating terminology? Maybe "registry metadata" and "serving metadata"?

I guess "feature (set) labels" could already suffice unambiguously for what I called "registry metadata". The feature in this PR being called "feature metadata" is problematic though, I think.

Just a very, um, meta thing—if I saw this changelog and #536 in the same release notes I would think they're related. Should we find some disambiguating terminology? Maybe "registry metadata" and "serving metadata"?

Yea I agree :)

Actually the Feast project has a long history of abusing the term metadata. It's just such a convenient word. It's everything Util, Spec, and Info aspire to be, and more.

How about

• Feature status metrics
• Feature status metadata
• Feature value statuses <- my preference.

It's everything Util, Spec, and Info aspire to be, and more.

I might steal that.

I think "feature value statuses" is apt.

Can we introduce this change/functionality in an evolutionary-friendly way? Like introduce it as a new RPC and new messages, with the old ones remaining supported, possibly going through a deprecation period before Feast 1.0?

Breaking the contract is extremely disruptive here. Upgrading the Serving API will break existing online clients in production, they will all have to upgrade their SDK, and it's not possible to roll out a forward-compatible SDK upgrade to fleets in advance. This breaks all the rules of API evolution.

@mrzzy any objections to feature value statuses?

Breaking the contract is extremely disruptive here. Upgrading the Serving API will break existing online clients in production, they will all have to upgrade their SDK, and it's not possible to roll out a forward-compatible SDK upgrade to fleets in advance. This breaks all the rules of API evolution.

We can. Some ideas on gRPC versioning from Microsoft.

We could add a new RPC with V2?

I renaming "Feature Metadata" to "Field Status" in the PR name instead of "Feature Status" as it also returns entity statuses in addition to feature statuses.

The golang code has to be versioned too, since version pinning is a non-goal of go modules :/

This is a good example I think in favor of SDKs providing higher-level API wrapping protobuf types and request/response objects—this Java API was seamlessly upgraded in the PR, and the same could apply to using a new RPC underneath and phasing out the old one:

public List<Row> getOnlineFeatures(List<String> features, List<Row> rows, String defaultProject)

while this is very susceptible to source-incompatible breakage, at least if user code touches the (public) underlying RawResponse:

func (fc *GrpcClient) GetOnlineFeatures(ctx context.Context, req *OnlineFeaturesRequest) (
	*OnlineFeaturesResponse, error) {

The golang SDK follows a similar pattern, but unfortunately for golang the proto-generated code is persisted (and versioned) together with the sdk code :(

type Client interface {
	GetOnlineFeatures(ctx context.Context, req *OnlineFeaturesRequest) (*OnlineFeaturesResponse, error)
}

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mrzzy, woop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/test test-end-to-end-batch